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Carnegie Mellon University 

Software Engineering Institute 


Environment Concerns 

/ ♦ User 

- conceptual integrity 

- tool integration 

- new tool additions 

- life-cycle coverage 

- method supported 

- language(s) supported 

- hardware fjase 

• Environment architect 

- software architecture 

- representation of objects 

m 

9 9 9 

• Tool builder 

- interfaces 

m 
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Carnegie Mellon University 

Software Engineering Institute 

4 

Environment Roulette 

• Backing into environments - incrementally 

\ 

7 • False economy - focus on hardware 

• Lure of the PC - scaling up 

• Heterogeneity 
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Tool Integration and Tailoring 

• Because of heterogeneity and risk factor of 
monolithic, single vendor environment: 

- assembly of components, e.g., design tool, code 
generator, document preparation, mailer, editor 

- tailorability of tools and their interaction 



Carntgl* Mtllon Untv«i*lty 
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Software Heterogeneity 

• Host target software development and maintenance, 
e.g., Ada embedded systems ' 

v 

• Distribution of life-cycle support across machines 
requiring integration, e.g., NASA Space Station 

• Different services on different hardware 

• Different models, e.g., access control, project 
management; configuration management 



Cwnegl* Mellon Unlve/tity 

Software Engineering Institute 

Implications 

• Architecture 

- language-centered 

- process-driven 

• Tailorability 

• Software maintenance 
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Problems 

• Remote resource management (not centralized) 

• Integration of hardware for different services 

• Data interoperability; 

• life cycle or life-cycle phase 

• between tools and between machines 

• Hardware changes over life cycle 

• Need transparent view via uniform interface 


Carnegie Mellon University 

Software Engineering Institute 

i 

Structure-Oriented 

• Common representation , 

* 

• Editor-controlled 

• Multiple views 

• Semantic-directed browsing 

• Examples - Gandalf, Rational, Cornell Synthesizer 
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Method/Process-Based 

Method-based. 

• Support specific method 

• Often include graphical representation 

• Some formal foundation 

• Examples - JSD, SADT, SA/SD, Statemate, Refine 

- 1 

Process-based 

• Support a specific process model 

• Enforce a discipline 

• Language independent 

• Examples - Refine, ISTAR 
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Carnegie Mellon University 

Software Engineering Institute 


Toolkit 

• Operating system extensions 

• Language independence 

• Standard interface 

• Generality - tools applied to files 

• Team cooperation requires discipline 

• Examples ■ UNIX PWB, CAIS, PCTE 
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Carnegie Mellon University 

Software Engineering Institute • 
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Language-Centered 

• Support for semantics of specific language 

• Interactive 

• Incremental 

• Encourages exploratory development style 

• Examples • Interlisp, Smalltalk, Cedar, Rational 
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Management Support 

• Management of resources 

i 

• Management of product 

• Management of process 

• Management of environment 
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Environment Trends 

• Toolkit 

• Language-centered- ' 

• Structure-oriented 

• Method/process-based 
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Carnegie Mellon University 

Software Engineering Institute 

i 

Motivation for 

Software Development Environments 

• Programming support tools ■ 

• Management of complexity 

• Support for the process 
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Integration 

• Conceptual - across life cycle phases 

'i 

• Tool - permit tools to pass data 

• User interface - user interacts in consistent manner 

• Language centered - assumes activities in specific 
language 

• Incremental - tools are finer grained - spreadsheet 

• View - allow multiple views 


* Not necessarily mutually exclusive 
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Strengths 

• Usual benefits of automation: consistency, 

repeatability (plus some inflexibility) 

• Working representations are captured, online, and 

deliverable 

• Increasing ability to not only analyze, but also query 

and browse 

• Less time spent during inspections and walkthroughs 

on syntax errors, and more time spent on errors of 
substancp 
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Cprnegie Mellon University 

Software Engineering Institute 

Trends 

• Animation of state transition models of behavior 

i 

>• 

• Performance modeling 

• Enthusiasm for object-oriented design 

• Integration of tool sets with different capabilities 
from different vendors 


Deliverables satisfying 2167 
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Tools Taxonomy 
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C*/n»jlt Mtllon Univ»i»ily ; 

Software Engineering Institute 

Evaluation Attributes 

• Ease of use 

• Power 

• Robustness 

• Functionality 

• Ease of insertion 

• Quality of support 
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Classification of Methods 


View 

of 

Problem 


Stages of Development 



specification 

•' design 

implementation 


functional 

data flow 
diagrams 

PDL 

, 


structural 

entity 

relationship 

diagrams 

helrarchlcaf 

structure 

charts 



behavioral 

state 

transition 

diagrams 










• Different views dominate at different stages 

• Views are complementary 
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Software Engineering Institute 

Tools 

• Software supporting the software development 

process , 

• Publicly available and supported 

- Offered in expanding commercial market 

• Value provided through 

- Relevance to required development activities 

- Assistance to human labor 
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Software development Environments 
Status and Trends 

Software Engineering Institute 
Carnegie Mellon University 
Pittsburgh, PA 15213 

Sponsored by the 
U.S. Department of Defense 




TOOL AND DATA INTEROPERABILITY 
IN THE SSE SYSTEM 


Design Approach for Transformation Procedures 

• Identify Common Subset of Tool Capabilities 
- Requires Detailed Understanding of the Tool 

Suite as well as Application Domain 


• Develop Text-based, Machine-readable Representation 

- Text-based format avoids machine-dependencies 

- Compiler Technology can be Applied in most Cases 

• Common Interoperability Format should be Hidden from 
Applications, unless it is their Native Format 

- Allows easy modification of Interoperability Format 

• Transformation Procedures Require Similar support 
routines. Design for Portability and Reuse 

- Up to 75% of code in an Interoperability to Tool 
Transformation Procedure is common. 













InteroDerabilitv Overview 
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TOOL AND DATA INTEROPERABILITY 
IN THE SSE SYSTEM 


Interoperability Solution 

• Develop Data Interoperability Formats for Each 
Class of Design and Development Tool 

• Provide Application-level Views of Data, 

Versus Network, O/S or File System Views 

• Tool/Data Interoperability Is Related to 
Information-bearing Entities, Not Physical 
Implementations or Interpretations 

• Interoperability Formats Support the Intersection 
/ of Tool Capabilities, Not the Union 






TOOL AND DATA INTEROPERABILITY 
IN THE SSE SYSTEM 
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Interoperability Overview 
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TOOL AND DATA INTEROPERABILITY 
IN THE SSE SYSTEM 


SSE Interoperability Issues 


• Multiple Hosts in a Distributed Environment 

- Vax/VMS 

- IBM/VM 

• Multiple Workstations Networked to Hosts 

- Apollo 

- Macintosh II 

- IBM PS/2 
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TOOL AND DATA INTEROPERABILITY 
IN THE SSE SYSTEM 



• Design Tool Interoperability 

- Cadre Teamwork, Icopix PowerTools, Excellerator 

• Graphics Development Tool Interoperability 

-Interleaf, MacDraw, GEM Draw 

• Document Development Tool Interoperability 

- Interleaf, Microsoft Word (RTF and DCA Formats) 

• Document Production 

- Scribe, Postscript 



TOOL AND DATA INTEROPERABILITY 
IN THE SSE SYSTEM 



Commonality of Data and Information 


Information Exchange between Diverse Tool Sets 


Interoperability between Heterogeneous Hosts 


Interoperability between Heterogeneous Tools 





• Common Hardware Architecture 

- IBM 360, SDP, Various PC Standards 


• Common or Standard Operating Systems 

- CP/M, MSDOS, Unix/POSIX 

» Industry-developed Data Formats 

- DIFF, DCA, RTF 

- IGES, TIFF, GIF 

- EDIF 

• Stand-alone Tool Integration 

- Mac O/S 

- Software Backplane 
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Tool and Data Interoperability 
in the SSE System 


Chuck Shotton 
PRC 

11 / 10/88 




• Industry Problems with Program and Data Interoperability 

• SSE System Interoperability Issues 

• SSE Solutions to Tool and Data Interoperability 

• Attaining Heterogeneous Tool/Data Interoperability 
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Software Engineering Institute 


Software Development Methods 

• Representations 


• Deriving the representations 


• Examining the representations 
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Software Engineering Institute 


Goals 

• Maintain separation of methods from tools 
supporting the methods , , . 

• Point of view of methods and tool users, not 
tool-builders 

• Separate classification from evaluation 

• Repository for information 

• Determine "gaps" in methods and tools 


SPIRAL MODEL OF SOFTWARE PROCESS 
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Carnegie Mellon University 
Software Engineering Institute 


Process Definition 

• A sequence of life cycle tasks, which when properly 
executed produces the desired result 

• An effective process must consider* 

- the relationships of all the required tasks 

- the fools and methods used 

- the skills, tiaining, motivation, and management of the 
people involved 


Carnegie Mellon University 

Software Engineering Institute 

Strategy 


Promote the evolution of software engineering 
from an ad hoc, labor-intensive activity to a 
managed, technology-supported discipline 
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Implementation of Strategy 

, 

• Put process under management control 

- defirje 

- measure 

- optimize 

> Adopt appropriate methods 

• Insert technology that provides automated support for 
the process and methods 

• Collect automated tools into an integrated environment 

• Educate people 
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CASE 

• Process 

• Methods 

Components • Computers 

• Tools 

• Support environments 

• Engineers 

Currently the engineers are the essential 
Integrating factors tying all these components 
together 

The engineers today empower the tools 
versus, 

the tools empowering the engineers 
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Issues in Software Engineering 

• Quality 

- correctness , 

■ reliability 

- performance 

* 

• Managing the software engineering process 

- costs 

- schedules 

• Productivity 

- individuals 
• groups 
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PROCESSES/METHODOLOGIES 


Howard Yudkln 




OK For Small Projects, Not So Good For Large Projects 

Not Good For Addressing Iterative Nature Of Requirements 
Resolution & Implementation (Mostly Based On Waterfall) 

Does Not Address Complexity Issues Of Requirements 
Stabilization (Based On Functional Decomposition) 

Does Not Explicitly Address Reuse Opportunities 

Does Not Help With People Shortages z 


NEED TO DEFINE AND AUTOMATE IMPROVED 
SOFTWARE ENGINEERING PROCESSES 
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SOFTWARE 
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REUSE AND PROTOTYPING -TWO SIDES OF THE SAME COIN 

k : 

» ■ ’ 

• Reuse Library Parts Are Used To Generate Good 
Approximations To Desired Solutions, i.e., Prototypes 

• Rapid Prototype Composition Implies Use Of Pre-existent 
Parts, I.E., Reusable Parts 

- Prototype Quality Depends On Fit Of The Available 
Parts 

- The Parts Will Often Require Some Adaptation 

- As The Set of Parts Available Becomes Richer The 
Prototypes Will Better Approximate Acceptable Pieces of 
Final Systems 



SOFTWARE 

RODUCT1VITY 
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REUSE PAY-OFF 


Big Gains In Productivity 
Will Come From Reusing 
Fewer Larger Parts Or 
Assemblies Of Smaller Parts, 
Not From Many 
Unassembled Small Parts. 

Productivity Gain vs Cost Is 
Acceptable If Assemblies Of 
Parts Are Reused Frequently. 


R 

E 500%. 

L 

A 450%. 
T 

1 400%. 

V 

B 350%. 


80% Proportion of Reused Code 


250%. 


£ 300%. 

£ 250%. 

U 

C 200%. 
T 

I 150%. 
V 

1 100 %. 


20% 40% 60% 80% 

RELATIVE COST TO REUSE 


100 % 
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SYNTHESIS MOTIVATED BY AND ORIENTED TOWARD 

» ' 

/ 

• Reuse: Exploit Similarities Across Systems 

• Iteration: Feedback and Enhancement 

• Composition and Adaptation: Using Standard Schemes, Parts, 
and Designs 

• Specialists: Incorporate Expertise, and Facilitating and 
Coordinating 

• Systems View: Engineering Process 

• Applying Synthesis to “Synthesizer” 
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THREE MAJOR SYNTHESIS SUBPROCESSES 
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LIBRARY CONTENTS 

\ 

Application Models 

Design Models 

% 

Executable Code 




TARGET APPLICATIONS FOR 
DOMAIN ANALYSIS - 
AIRPLANE EXAMPLE 









ESSENCE OF DOMAIN ANALYSIS 






/ 




Each application area must be analyzed and characterized by 
standard designs or architectures that capture the way that many 
systems in that area could reasonably be built. 

The application engineer must be able to state his needs in 
application terms and have those needs mapped appropriately 
to an instance of the standard design. 

The design instance can be realized by specification of a set of 
parts from a reuse library and a set of rules for combining 
those parts. 
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SYNTHESIS SUBPROCESS - SCAVENGING 

Many systems with software have portions amenable to 
adaptation for reuse. 

Scavenging these systems for reusable parts involves: 

- Extraction 

- Generalization 

- Standardization 

- Certification 

- Cataloging and storing in reuse libraries. 
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A MISSILE GUIDANCE SYNTHESIS PROTOTYPE TOOL 

An example of the application of reuse, prototyping, and synthesis 
using a reuse library in a specific domain 

• Based on U.S. Air 
Force “Common Ada 
Missile Packages” 

(CAMP) parts 

• Initially demonstrates 
a longitudinal 
autopilot control sys- 
tem 

• Aids understanding of 
the economics of 
reuse 

JXMKF SOFTWARE 
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LONOITUDINAL 
AUTOPILOT 
NTROL PARAMETE 




CAMP Parts 
Composition 

Rulci — 


Adapt 

(LQ synthesis) 


Executable Ada 
prof ram (or 
lon|iiudinal autopilot 
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PARTS OF SYNTHESIS/SYNTHESIZER 


Reuse 

Libraries 


Application 

System 

Modeling 

Toolset 


Scavenging 


Domain Independent 


Design 


Dynamics 

Assessment 


Composition Traceability 


Coding 


Verification 


Management I OA and 
fc Coordination Documentation 


Project 

Library 

& 

Work 

Areas 


System Development & Evolution 
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A METHODOLOGY FOR PARTS SPECIFICATION 
AND MODEL ASSEMBLY IS EVOLVING ' 

Based On NRL Software Cost Reduction Methodology 

- Information Hiding Module Families 

- Abstract Interfaces 


Accommodates Ada Packaging And Tasking Concepts 
- Tasking Guidelines Evolved (ADARTS) 

Initial Guidebooks Written And In Use 
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PRODUCT SET 1A STRUCTURE 




Informational 

Filters 


AAD 

Editor 


Printer 


Diagram 

Graphical 

Database 


AutoLayout 


PDL File 


PDL File 


PDL— >DIANA 



RADC DIANA 
Dlagrammer 
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THE LAYERED REPOSITORY CONCEPT 




ONE FOR EACH MEMBER 
COMPANY NETWORK 
LOCATION 


ONE FOR EACH PROJECT 


REPOSITORY 


PROJECT 


DISTRIBUTED 

DATA 

LEVEL 


Of(E OR MORE FOR 

EACH DATABASE LOCATION 


CREATED BASED ON 

PROJECT NEEDS 

( COLLECTIONS CAN CONTAIN DATA OBJECTS 
A NO/OB OTHER COLLBCTIONS ) 



INDIVIDUAL 

DATABASE 

LOCATION 

LEVEL 


ACTUAL DATA 
OBJECTS. 


OBJECT 

i i i i i i LEVEL 

INCLUDES BOTH RDBMS STORAGE AND COTS CM STORAGE 
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TYPICAL PROJECT LIBRARY ACCESS 


APPLICATIONS CODE 

- D8SION TOOL 

- ASSESSMENT TOOL 

- TRACEABILITY 

- HARNESS TOOLS 

- MC DEVELOPED 
TOOLS 


TOOLK 


TYPICAL COMMANDS 


DATA OBJECT RELATED 

- CREATE DATA OBJECT 

- DELETE DATA OBJECT 

- CHECK OUT DATA 
OBJECT BODY 

- CHECK IN DATA 
OBJECT BODY 

- GET ATTRIBUTE 

- SET ATTRIBUTE 

- OBT CONTENTS LIST 


RELATIONSHIP RELATED 

- CREATE RELATIONSHIP 

- DELETE RELATIONSHIP 

- OBT ATTRIBUTE 

- SET ATTRIBUTE 


UNIQUE ID RELATED 

- PATHNAME TO UID 

- RELATIONSHIP TO UID 


QUERY RELATED 

- FETCH BY ATTRIBUTE 
VALUE 

- OBT RELATIONSHIP 
TYPES 

- GET RELATIONSHIPS 


DMS CODE 


DAS/DMS 


COTS PRODUCTS 




DYNAMIC SQL INTERFACE 


ATTOBUTES 

BELATIONSMPS 


TAILORED CODE 
INTERFACE 


\ 


COTS 

CM 


OBJECT BOOKS 
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ORIGINAL PAGE IS 
OF POOR QUALITY 




T reo eebaty Navigator 1 


NAV - TraoeabNty Navigator 


Requirements objects In /xyz/abc/det/JM 
Subset: data > 860325, owner ■ Johnson 


17 total 
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Data 


12Sep8Q 
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17Aug88 


Tracing relatkmahlpa to a aat 
of ralatad objects 




check constraint 
make re port -> 
create ratal 
deselect al 


loots-> 


NAV - Trace Relationships 


Tracing from requirements objects In NAV window t 


tptcl/t 

relationship 

•»*(*) 


■ lasted by 

□ implemented by 
n derived from 

□ described In 

o sllfcsl Hksdilo 


specify scope of tracing 


/V 23 CCMS 


tool 
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IMPACT ANALYSIS TOOLSET OVERVIEW 



Person 


Initial Impact Set 


Pfiiimm i Inpact Sac 



Person 


Verify that person 
inape ctad/chan|«d all 
objecu In the change 
Uit 


OBJECT CHANGE LIST: 
List of impacted objects to 
exaplne 



Perform' 

yChangeV 


|No 

Forget Itl 


Manager/ 

Con fig. Control Bd. 


Impede on 
Projed Schedule 
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Concurrent Computer Corporation 

Westford, MA 
(508) 692-6200 

cdj@cs.cmu.edu, uuneLuu.net! masscompljensen 


University of Houston RIC1S and NAS A/Johnson Space Center 

Symposiwjuon 

Integrated Computing Environments for Large. Complex Systems 

November 10. 1988 





Concurrent 


a 

Outline 


• System Integration and Operation (SIO) Requirements 

• New Generation Technical. Approaches for SIO 





• Real-time 

• Distribution 

• Survivability 

• Adaptability 

! 

i 

i 
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Concurrent 


a 

SIO Application Requirements 


Real-Time 

• The application, and thus the OS, activities have various 
types of stringent time constraints (e.g., hard and soft dead- 
lines) for their completion, which are part of the correct- 
ness criteria of the activities because they are critical to 
mission success and the survival of human life and property 

• SIO is a dynamic and stochastic environment 

• a high percentage of the activities are aperiodic with 
critical time constraints 

• not all periodic and aperiodic time- constraints can 
always be met, in which case application-specified 
recourse must be taken j 

I : 

• Activities have dynamic (time- and context-dependent) 
relative importance (functional criticality) as well as urgen- 
cy (time criticality) 

• The performance of the system, and of its os, must be opti- 
mized for high-stress exception cases, such as emergencies 
(e.g., due to faults, errors, and failures, or even hostile 
attack) 




Concurrent 


a 

SIO Application Requirements 


Distribution 


• Each system consists of many subsystems containing single- 
and multiple- processor machines which, for technical and 
logistical reasons, are loosely interconnected (i.e., via i/o 
paths such as buses or links) — 

in some systems, the subsystems may be physically dispersed 
across tens or even hundreds of meters 

• These interconnected machines constitute a single inteerat- 
ed computing system, dedicated to a particular application, 

executing complex distributed programs 

I 

i 

• A multiplicity of such systems bommunicate application 
data and status among one another, and are implicitly or 
explicitly coordinated in their mission activities — 

the distances among systems may be hundreds of meters 

• System integration and operation is automated, and under 
the control of a (human) hierarchical command authority 


acstus«*jsc *r*oemjK 




i 


k 




Concurrent 


a 


SIO Application Requirements 


Survivability 


• The computing system must tolerate conditions far more 
severe than those encountered in non-real-time contexts 

• some systems are subject to hostile attack, so their 
hardware faults tend to be clustered in space and time 

• different systems have a wide variety of mission peri- 
ods for which there is no single robustness approach: 
from hours to decades 

• limited or no repairs may be possible during the mis- 

, sion 

• the system usually has to remain in non-stop service 

during recovery from faults i 

i 

• extreme safety concerns: system failure may jeopar- 

dize the mission, human life, and property 

• Because the hardware and software are distributed, there 
are multiple independent fault modes 

• Overloads, faults, and resource contention are inevitably 
dynamic and stochastic 

• Optimal performance under exceptional stress is the raison 
d’etre of the system 
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Concurrent 


a 

SIO Application Requirements 


Adaptability 

• Application limitations often demand maximum comput- 
ing capability for the allowable size, weight, and power, 
which argues for special-purpose hardware and OS; 

but there is not just one set of fixed computing require- 
ments 

• There are many widely divergent real-time SIO applica- 

tions, and the high costs of developing their computing sys- 
tems argues for generality, standardization, and re-usability 
of the hardware and OS . , 

• The computing requirements for any particular application 
evolve continuously over the entire lifetime; of the system 
because 

• the application is extremely complex and difficult to 
understand 

• the application environment varies with time 

• technology advances rapidly 

and the application system lifetime can be decades 
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New Generation Technical Approaches 
for System Integration and Operation 


• Real-Time 

• Distribution 

• Survivability 

• Adaptability 
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New Generation Technical Approaches 
for System Integration and Operation 


• Manage all physical and logical resources directly with 
actual application-specified time constraints as expressed 
by time-value functions for all activities — 

• manages periodic and aperiodic activities in an inte- 
grated, uniform manner 

• distinguishes between urgency and importance 

• allows not only hard deadlines but also a wide variety 
of soft (i.e., residual value) time constraints 

• accommodates dynamic variability and evolution of 
both periodic and aperiodic time constraints j 

• provides behavior which is as deterministic as desired 
and affordable 

• handles overloads gracefully according to application- 
specified policies 

• supports the clean-up of computations which fail to 
satisfy their time constraints, to avoid wasting 
resources and executing improperly timed actions 

• employs the same block-structured, nested, atomic 
commit/abort mechanisms as for transactions 


Optimize performance for exception cases 
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New Generation Technical Approaches 
for System Integration and Operation 

Distribution 


• Provide a new programming model which is well-suited for 
writing large-scale, complex real-time distributed software: 

objects (passive abstract data types — code plus data), in 
which there may be any number of concurrent control 
points; and threads (loci of control point execution) which 
move among objects via operation invocation 

• A thread is a distributed computation which transparently 

(and reliably) spans physical nodes, carrying its local state 
and attributes for timeliness, robustness, etc.; , 

j 

these attributes are used at each node to perform resource j 
management on a system-wide basis in the best interests i 
(i.e., to meet the time constraints) of the whole distributed 
application 

• Distributed computations must explicitly maintain consis- 
tency of data and correctness of actions, despite asyn- 
chronous real concurrency (and multiple independent hard- 
ware faults) — to accomplish this requires (at the kernel 
level, because the os must itself be distributed) 

• real-time transaction mechanisms for atomicity, appli- 
cation-specific concurrency control, and permanence 

• system- and user-supplied commit and abort handlers 
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New Generation Technical Approaches 
for System Integration and Operation 

Survivability 


• The survivability properties and approaches include 

• graceful degradation: best-effort resource manage- 

ment policies; dynamic reconfiguration of objects 

• fault containment: data encapsulation (objects); 

object instances in private address spaces; capabilities 

• consistency of data, correctness of actions: concurren- 
cy control objects; resource tracking; thread mainte- 
nance; abort blocks; realtime transaction mecha- 
nisms (atomicity, concurrency control, permanence) 

• high availability of services and data: object replica- 
tion; dynamic reconfiguration of objects 

• The survivability features are presented through the pro- 
gramming model as a set of mechanisms which can be 
selected and combined as desired — their cost is propor- 
tional to their power 

• Transactions 

• are scheduled according to the same real-time policies 
as are all other resources 

• allow application-specific commit and abort handlers 
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New Generation Technical Approaches 
for System Integration and Operation 


Adaptability 

• Adhere to the philosophy of policy! mechanism separation : 

• have a kernel of primitive mechanisms from which 
everything else is constructed according to a wide pos- 
sible range of application-specific policies to meet par- 
ticular functionality, performance, and cost objectives 

• provide these mechanisms at the optimal level of func- 
tionality — i.e., both necessary and sufficient to create 
large scale, complex real-time distributed systems 

• Encourage application-specific information- to be exploited 
statically and dynamically — e.g., 

• special-purpose objects can be migrated into the kernel 

• references to objects can be monitored for locality ■ 

• any attributes can be carried along with threads 

• special hardware augmentations can be objects 

• concurrency control and abort handlers can be special 

• resource management policies are application-defined 

• Employ elastic resource management which flexes to toler- 
ate variability in loading, timing, etc. 
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Alpha Program Management Overview 


• Alpha originated at CMU-CSD as part of the Archons Pro- 
ject on real-time distributed computer architectures and 
operating systems — Doug Jensen was the Principal Investi- 
gator 


• As part of a long-continuing “Think — Do” cycle, new con- 
cepts and techniques were created, based on the Pi’s 15 
years of industrial R&D experience with real-time comput- 
er systems, 

then many of these were embodied in a feasibility test vehi- 
cle: the Alpha real-time decentralized OS 

• The Alpha prototype (“Release 1”) 

• lead by Duane Northcutt, with a team of five program- 
mers for about three years 

• written for (homebrew) multiprocessor Sun worksta- 
tions connected via Ethernet 

• consists of a high-functionality kernel, some system- 
layer functions, some software development tools 

• installed at General Dynamics/FL Worth in 1987 and 
demonstrated to many DoD agencies with a real-time 
C 2 application 

• numerous technical reports now becoming available 



1 
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Alpha Program Management Overview 

(continued) 


• Alpha Release 2 

• intended to make the technology externally accessible, 
on reproduceable hardware platform, and further 
develop it 

•. kernel interface spec subcontracted by CMU to 
Kendall Square Research, which Jensen later joined 

substantial functional enhancements were included 

• initial detailed design subcontracted to Concurrent 
when Jensen moved there 

• continuing research and remainder of design and 
implementation is part of a pending procurement 

• Jensen’s Ph.D. students continuing research at CMU 

• pre-release available mid-CY89, release^ at end of 
CY89 

• portable, open, multi-vendor hosted 

• Release 3 

• significant enhancements over Release 2 
« release at end of CY90 
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INTRODUCTION 


i 


• , > 

ADVANCED PROJECTS SECTION 


• ELEMENT WITHIN MISSION OPERATIONS DIRECTORATE 

• RESPONSIBILITIES 

• DEVELOP/COORDINATE USER REQUIREMENTS FOR GROUND 
INFORMATION SYSTEMS SOFTWARE (E.G., MISSION CONTROL CENTER 
UPGRADE) AND TRANSMIT TO DEVELOPER. 

- REPRESENT OPERATIONS COMMUNITY (USERS) TO DEVELOPER. 

- REPRESENT DEVELOPER TO USERS. 

- DEVELOP/PROTOTYPE USER APPLICATIONS. 

• PROVIDE CONFIGURATION MANAGEMENT OVERSIGHT FOR USER 
APPLICATIONS. 



PROBLEM 


• SOFTWARE PRODUCTS OF THE CURRENT DEVELOPMENT PROCESS OFTEN 
DO NOT FULLY MEET "TRUE" USER NEEDS UPON DELIVERY. 

- DELIVERY OF NEEDED CAPABILITIES IS DELAYED. 

- COST OF CORRECTING SYSTEMS AFTER DELIVERY IS HIGH. 


• PROBLEM IS ROOTED IN REQUIREMENTS DEFINITION AND ANALYSIS 
PROCESS. 



CAUSES 


REQUIREMENTS DEFINITION FOR CONTEMPORARY INFORMATION 
SYSTEMS IS INHERENTLY DIFFICULT. 

- HIGH HUMAN/COMPUTER INTERACTION 

- APPLICATIONS DEVELOPED BY USER COMPLICATES APPLICATION 
INTERFACE REQUIREMENTS DEVELOPMENT 

REQUIREMENTS CHANGE RAPIDLY. 

- USER POPULATION IS DYNAMIC. 

- USER APPLICATIONS ARE CONSTANTLY EVOLVING. 

- NEW PROGRAMS (E.G., SPACE STATION) INTRODUCE NEW OPERATIONS 
CONCEPTS. 

- NEW TECHNOLOGY IS CONSTANTLY EMERGING. 

- EXPERIENCE WITH CURRENT SYSTEM UNCOVERS NEW REQUIREMENTS. 



CAUSES (CONTINUED) 


REQUIREMENTS ARE OFTEN INCOMPLETE/CONFLICTING DUE TO DIVERSITY 
OF USER COMMUNITY. 

- TASKS 

- FLIGHT SYSTEMS (E.G., DISCRETE VS. ANALOG. TELEMETRY VS. 
TRAJECTORY) 

• USER EXPERIENCE LEVEL 

REQUIREMENTS ARE EASILY MISINTERPRETED ELOPER. 

- USERS ORGANIZATIONALLY SEPARATED FROM DEVELOPERS. 

- WRITTEN DESCRIPTIONS OF VISUAL SYSTEMS IS INADEQUATE. 

THESE CONDITIONS ARE NOT UNIQUE TO NASA MISSION OPERATIONS. 



INTRODUCTION TO SESSION 1 


REQUIREMENTS ANALYSIS FUNDAMENTALS 

• "REQUIREMENTS ANALYSIS, DOMAIN KNOWLEDGE, AND DESIGN," COLIN 
POTTS/MCC SOFTWARE TECHNOLOGY PROGRAM 

SUGGESTS INNOVATIVE METHODOLOGY TO: 

• ACCOMMODATE CHANGING/CONFLICTING REQUIREMENTS. 

- SYSTEMATIZE TRANSLATION OF REQUIREMENTS INTO DESIGN, 
REDUCING MISINTERPRETATION. 

- IMPROVE REQUIREMENTS COMPLETENESS. 

- ENHANCE TRACEABILITY. 


INTRODUCTION TO SESSION 1 (CONTINUED) 


• "KNOWLEDGE-BASED REQUIREMENTS ANALYSIS FOR AUTOMATING 
SOFTWARE DEVELOPMENT," LAWRENCE MARKOSIAN/REASONING 
SYSTEMS, INC. 

PROPOSES NEW SOFTWARE DEVELOPMENT PARADIGM THAT: 

- AUTOMATES DERIVATION OF IMPLEMENTATIONS FROM 
REQUIREMENTS, REDUCING MISINTERPRETATION. 

- INCREASES DEVELOPMENT PRODUCTIVITY. 

- VALIDATES FORMALIZED REQUIREMENTS. 

- ENHANCES TRACEABILITY. 
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SCIENCE TO ENGINEERING 




RICIS '88 


DEFINITIONS OF ENGINEERING 


‘...application of 
mathematical and 
scientific ‘bodies of 
knowledge' as 
captured by 
predictive models, 
laws, etc. to the 
problem of designing 
and constructing 
economical and 
reliable systems 
which fulfill some 
real need.** 


.. establishment and use 
of sound engineering 
principles to obtain 
economical software that 
Is reliable and works 
efficiently on real 
machines'* 



RICIS '88 


Engineering 


Tailor (Craft) 


Tinker 

(Pre-Craft) 



DEVELOPMENT OF COMPUTING: 
A PERSONAL MODEL 



w 


SOFTWARE ENGINEERING 



RICIS '88 


CHALLENGES 

i 


> — i— — ^ 

HOW TO GET 4-5 YEARS OF 
CONTENT PACKED INTO A 
CURRICULUM 

L 


( VERIFYING THE 
DESIGN 


^DEVELOP MODELS OF A 
MATURE DISCIPLINE, E.G. 
MAXWELL’S EQUATION OR 
NEWTON’S LAWS 
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Empirical Studies of Software Design: 

Implications for SEEs 


Herb Krasner 

Manager, Software Process Research 
Lockheed Software Technology Center 
Austin, Texas 


''^'Lockheed ^ 

Missiles & Space Company, Inc. 


Software Technology Center 


411 758 





Empirical Research on the Software Process 



8 experienced pro- 
grammers designing 
the control structure 
for a set of elevators 
during an intense 2 
hr. session 


Videotaped team 
meetings from a 7 
mo. effort to design 
and build a tool to 
support object ori- 
ented programming 


Detailed interviews with 
key members of 18 large 
development projects to 
model their decision- 
making and communication 
process 


Participant nxporliiiontor 



Ctislnmor 

tUillll 


jrS'L v 

Project l'“l' 

lonin < 

Ohsorvors 



^ ^Lockheed 

Missiles & Space Company, Inc. 

Sollwaro Technology Contor 1 1759 





Results of the Field Study 


• Observations about commonality/difference of projects 

• Identification of five areas of organizational breakdown (within 
that sixteen specific problems) 

• Implications for process modeling 

• Mapping of problems onto lower-level phenomena 


"You need to understand, this project isn't the way we develop 
software at our company." 


^ ^Lockheed 
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Characteristics of Projects Studied 



Stage ol 
Life Cycle 


Characteristics 


Pro- 

ject 

KLOC 

Real 

“time 

Dist. 

Sys. 

Emb. 

Svs. 

Gov. 

Application 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 
17 

Terminated 

Development 

Development 

Development 

Design 

Development 

Development 

Maintenance 

Development 

Maintenance 

Development 

Maintenance 

Design 

Maintenance 

Development 

Maintenance 

Requirements 

24 

50 

50 

70 

130 

150+ 

194 

250 

350+ 

400 

500 

725 

1000 

50k+ 

100k+ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

Support Software 
Radio Control 
Process Control 
Operating System 
CAD 
CAD 
Avionics 
C 3 

Compiler 
Run-time Library 
Compiler 
Transaction Proc. 
Telephony 
Operating System 
Telephony 
Radar, C 3 
C 3 , Life Support 


Lockheed 
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Summary of Results from MCC Field Study* 


• Analysis of three significant problems 

• Layered behaviorial model of software processes 

• Conclusions and implications 


* Papor appearing in this months CACM 
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Analysis of Three Significant Problems in Software Design for Large Systems 




Layered Behavorial Model of Software Processes 
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Business Mijieu 


’ Company 


Project 


Team^^'N 


X 


Individual 


Cognition and 

Group 

Organizational 

Motivation 

Dynamics 

Behavior 
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Implications of Field Study Results 


• For Software Technology 

- Environment support needed for: 

- Knowledge integration 

- Change facilitation 

- Broad communication and coordination 

- Beginnings of an empirical model to measure improvement for a tool/practice 

• For Project Management 

- Expertise is the primary determinant, new ways of effectively organizing should be pursued 

- Key role players identified and described: 
superconceptualizer, diagnostician, .gatekeeper, boundary spanner 

- Coordination by shared model of process, product 

• For Software Process Models 

, - Difference between prescriptive and actual processes 

- Current process models do not reflect: 

learning, technical communication, requirements negotiation, and customer interaction 

- Framework for an "ideal" process model emerging 

• For Further Empirical Research on Professional Software Engineering 

- Much more to do 

- Focus on "variation" and its effect on the difference in productivity and quality outcomes 
among people, situations, and their interaction 
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The Software Project as an Ecological System 


Changing World 


Industry and Company 
P&P, Standards, Etc. 


Project 


Assimilation of knowledge 
Communication and coordination 
Managing change 

Issue^esolution and decision making 
Technical design 

Organizational bureaucracy A 


Application 

Knowledge 


Contracting / 
Mechanisms 


Specific Needs 
or Customers 


^frLockheed 

Missiles & Space Company, Inc. 

Soltwaie Technology Cenlor 1 1 766 
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Overall Conclusion 


The Greatest Leverage Is in Supporting the Intersection of: 


The Technical Task 

• Assessing customer needs 

• Assimilating application knowledge 

• Negotiating requirements, technology, and resources 

• Identifying and exploring design assumptions/alternatives 

• Decomposing and recomposing functionality 

• Defining and controlling component interfaces 


The ManagementTask 

• Strategically managing system features and attributes 

• Assessing and controlling risks 

• Ensuring developers work from the same models 


'’^Lockheed 

Missiles & Space Company, fnc. 
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Results of the "LIFT" Study 


• Observations on relative effort distribution 

4 

• Observations abouLindividual differences 

• Identification of six process breakdowns 

/ • A cognitive model of design problem solving 


Lockheed 

Missiles & Space Company, Inc. 
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Information Model of Design Exploration 



/ 


assumptions 

scenarios 
of use 


test 

cases 


simulations 


constraints 


evaluation 

criteria 


discarded 

alternatives 


trade-off 

analysis 
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Individual Differences in Software Design Strategies 


Domain-Specific Strategies 


Exemplar driven 


Experienced 


Method (process) driven \ , nterme diate 


Computational paradigm driven 


Novice 


Trial and error driven 


Beginner 


General computation strategies 


Lockheed 
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Results of the Team Design Study* 


• Identification of conflict behavior as key to achieving shared models 

• Observations on the limitations of "documents" 

• Observation of ombudsman to facilitate communication between 
customer and design teams 

• Observations on the effect of midnight prototype creation 

• Videotape identified as history capture mechanism 


/ 

* being completed at U.T. - D. Walz, 1988 
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Future SSEs Should Contain Facilities For 


1) Focus on Productivity and Quality 

- Statistical QC 

- Reduce waste and redundancy 

- Institutionalized reuse process yields component parts (via standards) 

2) Process Engineering 

- Introduction of good practices, tools, etc. 

- Process definition, tailoring, monitoring, analysis, and improvement 

- Embodiment in education programs 

3) Process Efficiency through Teamwork and Communication 

- Revocation of Brook's Law 

- High performance teamwork 
-"Groupware" 

4) Flexible Organization Evolution 

- Coordinated technology, policy and organizational structure 
around process management concerns 

- Committment to improve (facilitatioaof change) 

- Capture of corporate domain knowledge (via issue-oriented domain analysis) 

- Negotiation-based requirements technology 

5) Liveware Support 

- - Variety of "experts" (stakeholders) 

- Significant variation in abilities 

'^frLockheed 

Missiles & Space Company, Inc. 

Software Technology Center #11773 
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Motivational Slide for this Morning 


In a study of 38 U.S. and Japanese Companies a wide variety of software management 
strategies were observed (Cusumano, 1 987). It Was concluded that Japanese firms are 
significantly ahead in applying a disciplined and flexible factory approach, as evidenced by: 


Japan 


.26 bugs 
1000 SLOC 


5% projects 
late 


34% reuse 


U.S. 


1000 SLOC 


43% projects 
late 


1 5% reuse 


^ ^Lockheed 
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THE ROLE OF SOFTWARE ENGINEERING 
IN THE SPACE STATION PROGRAM 


RICIS SYMPOSIUM 1988 
INTEGRATED COMPUTING ENVIRONMENTS 
FOR LARGE, COMPLEX SYSTEMS 


NOVEMBER 9-10, 1988 

v . 
0 
vr 

DANA HALL 

SPACE STATION PROGRAM OFFICE 

RESTON, VIRGINIA 
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SNAPSHOTS OF SOFTWARE ENGINEERING 
APPLICATIONS WITHIN THE 
SPACE STATION FREEDOM PROGRAM 






SOFTWARE ENGINEERING AND ADA TRAINING 


o SOFTECH (RICIS) 1987 SURVEY OF NASA: 

- OVER 150 ADA PROJECTS WITHIN 5 YEARS 
. MINIMAL EXPERIENCED PERSONNEL 

. MUCH SOFTWARE ENGINEERING AND ADA TRAINING 
NEEDED 

- FEW WRITTEN SOFTWARE DEVELOPMENT POLICIES 


o TRAINING RECEIVING MUCH MORE ATTENTION 
(but its still too little and maybe too late) 

EXAMPLES: 

- EXPANDED COMPUTER-BASED AND CLASS ROOM 
TRAINING FROM SSE 

- TOP MANAGEMENT ATTENTION 


SOFTWARE REUSE 


o WANT TO CAPITALIZE ON RESEARCH AND EXPERIENCE 
TO DATE 

- EXAMPLES: o ARMY 'RAPID* TOOL FOR 

LIBRARY MANAGEMENT 
o UNIVERSITY TAXONOMY/ 
ATTRIBUTES WORK 


o POLICY WILL ENCOURAGE REUSE 

- COMPONENT DEVELOPMENT 

- TRY DURING RAPID PROTOTYPING 

O PIVOT POINTS 

- CONTRACTOR INCENTIVES 

- ACCOUNTABILITY AND LIABILITY 




HIERARCHIAL COMMAND AND CONTROL 



Operation Management 
Ground Application 
(OMGA) 
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PROGRAM CHARACTERISTICS 
DISTRIBUTED SOFTWARE DEVELOPMENT & MAINTENANCE 




INTEGRATED, INTERNATIONAL ENVIRONMENTS 

(HOW MUCH IS NECESSARY FOR SPACE STATION FREEDOM PROGRAM ?) 


o ESA, NASDA, AND CANADA WILL PROVIDE MISSION/LIFE 
CRITICAL FLIGHT SOFTWARE 

. QUALITY OF PARTNER DEVELOPMENT ENVIRONMENTS 
UNKNOWN AND UNCONTROLLED 
. LIMITED EXPERIENCE IN MAN-RATED, COMPLEX 
SOFTWARE 

o HOW COMMON OR INTEROPERABLE MUST BE THE DEVELOPMENT 
ENVIRONMENTS? AND HOW DO WE ANSWER THAT QUESTION? 

- WRITE TIGHf INTERFACE SPECS? 

HOW CAN WE DETERMINE NECESSARY 
* DATA EXCHANGES? 

- PROVIDE THE SSE TO THE PARTNERS? 

P TECHNOLOGY TRANSFER (?) 

- SHARE A CRITICAL SUBSET? 

p STANDARDS? TOOLS? ALL OR PART? 

ENVIRONMENTS ARE TIGHTLY INTEGRATED 


THIS ISSUE MUST BE SETTLED SOON 



\ 

, \ 


r 

SOFTWARE PRODUCTION, INTEGRATION, AND MANAGEMENT 


s/w 

PROD. 

Acuities 



i FLIGHT 

i 




G1NAL PAGE tS 
POOR QUALITY 


INTEGRATED SIMULATION ENVIRONMENT 




























SOFTWARE ENGINEERING IS THE KEY TO MAXIMIZING PROGRAM "PROFIT" 
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BACKGROUND 



• SOFTWARE AUTOMATED VERIFICATION AND 
VALIDATION SYSTEM (SAVVAS) 

• ORIGINALLY DEVELOPED 

- FOR VAX/ VMS 

- USING DEC Ada 

• PORTED FOR NASA SPACE STATION SSE 

-TO IBM 3090/ VM 

- USING ALSYS Ada 
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BACKGROUND 






• SOFTWARE AUTOMATED VERIFICATION AND 
VALIDATION SYSTEM (SAVVAS) 

• ORIGINALLY DEVELOPED 

-FOR VAX/ VMS 

- USING DEC Ada 

• PORTED FOR NASA SPACE STATION SSE 

-TO IBM 3090/ VM 

- USING ALSYS Ada 
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SOFTWARE PORTABILITY 



An Cnyikyte- Comp»ny 


HOW DO WE IMPROVE PORTABILITY? 


• STANDARD LANGUAGE - Ada 

• ISOLATION OF NON-PORTABLE CODE 

• CONSTRAINTS ON LANGUAGE FEATURES 

• VIRTUAL INTERFACES 


SAC 
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HISTORY OF ADA 


1972 

1975 

1979 

1983 

1985 

1987 

1988 
1995 


DoD recognizes rapid growth cf software costs for military 
systems 

HOLWG reviews language requirements 

Ada selected from language design efforts 

Ada established as an ANSI standard 

DoD spends $1 1 billion on software 

Ada mandated by DoD directive 5034.2 
NASA awards Space Station SSE contract 

STARS Competing Primes contracts awarded 

DoD projected software spending is ever $25 billion 
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ISOLATION OF NON PORTABLK CODE 



• CAPITALIZE ON Ada'S FEATURES 
-PACKAGES 

• CLASSES OF DEPENDENT SOFTWARE 

- INPUT/ OUTPUT 

- DATABASE ACCESS 

- OPERATING SYSTEM SERVICES 
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SIMPLE TERMINAL INTERFACE PACKAGE 


package SIMPLEJTERMINALJNTERFACE is 

procedure GO_TO_POSTIION_(X, Y: in INTEGER); 

procedure DISPLAY_TEXT( MESSAGE: in STRING); 

end SIMPLEJTERMINALJNTERFACE; 

with TEXTJQ use TEXT IQ 

package body SIMPLEJTERMINALJNTERFACE is 

procedure GOJTO_POSITION_(X, Y: in INTEGER) is 
begin 

Send the appropriate code sequence to the terminal. 
These are different for varying terminal types. 

end GOJTO_POSTIION; 

procedure DISPL AYJTEXT ( MESS AG E in STRING) is 
begin 

•• Send the message to the terminal. 

- Induding any required code sequences 

end DISPL AYJTEXT, 
end SIMPLEJTERMINALJNTERFAC1-, 


SAIL ; 
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CONSTRAINTS OF LANGUAGE FEATURES 


• TASKS 

• PRAGMAS 

• GENERICS 

• EXCEPTION HANDLING 


SAIL 
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VIRTUAL INTERFACES 


• DATABASE ACCESS 

- Ada/ SQL 

- MODULE APPROACH 

• INPUT/ OUTPUT 

- X WINDOW 

- Ada-GKS 

• OPERATING SYSTEM _ 

- CAIS 

- PCTE 

- POSIX 
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MODIFICATIONS TO THE PLAY BOOK 


CONSISTENT DESIGN METHODOLOGY 
DESIGN AND CODING STANDARDS 


VIRTUAL INTERFACES 


COMPREHENSIVE Ada TRAINING 
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